코드 리뷰를 잘하는 방법:
코드를 이해하는 과정:
복잡하게 얽힌 파일 간 의존성을 잘 파악하는 방법:
그럴듯한 당연한 얘기만 한다. 써먹을만한 꿀팁은 없는가?
나쁜 코드 리뷰의 특징:
나쁜 코드 리뷰의 예시
"솔직히 말해서, 이 코드는 내가 본 것 중 가장 형편없어요. 이렇게 엉망인 코드를 제출한 걸 보면, 기본적인 프로그래밍 능력이 부족하다고 밖에 생각할 수 없어요. 처음부터 끝까지 모든 부분이 문제가 있어요. 코드의 흐름이 너무 끔찍해서 이해하기 힘들고, 이걸 읽는 내내 머리가 아팠습니다. 변수를 저렇게 짜놓은 이유를 도저히 알 수가 없어요. 이름만 보면 도대체 무엇을 의미하는지 전혀 감이 안 와요. 주석도 없어서 내가 어떤 기능을 구현하고 싶은지 전혀 알 수 없고, 그저 스스로가 이해한다고 생각하는 것 같은데, 다른 사람이 봤을 때는 완전 쓰레기 코드예요. 이런 코드 작성하느라 시간을 허비한 게 정말 아까운 기분이에요. 이 부분에서 이처럼 비효율적으로 코드를 짜는 건 정말 상상도 못할 정도로 어리석은 선택입니다. 게다가 이렇게 작성해놓고 오류가 발생할 확률이 아주 높아요. 이 코드가 제대로 돌아갈 가능성은 제로라고 봐도 무방해요. 솔직히, 내가 이 코드를 맡았다면 아예 다시 처음부터 끝까지 새로 짤 겁니다. 이건 그냥 시간이 아까워서 손 대고 싶지 않네요. 제발 이런 코드 작성하지 말고, 기본적인 것부터 다시 배우세요."
코드 리뷰에서 "착하게 쓰는 것"과 "나쁘게 쓰는 것"은 각각 장단점이 있지만, 올바른 선택은 상황과 목적에 따라 달라집니다. 그러나 "건설적인 피드백"이 가장 중요한 기준입니다. 이를 바탕으로 두 접근 방식을 비교하고, 올바른 선택을 분석해보겠습니다.
장점:
단점:
장점:
단점:
코드 리뷰는 단순히 잘못된 부분을 지적하는 것만이 아니라, 그 사람이 성장할 수 있도록 돕는 과정입니다. "착하게"와 "나쁘게"를 구분하기보다는 건설적이고 효과적인 피드백을 주는 것이 가장 올바른 선택입니다. 그렇게 해야 코드 작성자는 피드백을 잘 받아들이고, 개선할 수 있는 동기와 방향성을 가질 수 있습니다.
리뷰가 나쁘게 작성되었더라도 건설적인 피드백이면 괜찮을까에 대한 질문은 중요한 부분입니다. 건설적인 피드백은 내용의 개선을 촉진할 수 있기 때문에 긍정적인 측면이 있지만, 나쁜 방식으로 전달된다면 그 효과를 제대로 발휘하지 못할 수 있습니다.
다음은 이에 대한 자세한 분석입니다:
건설적인 피드백은 문제의 본질을 지적하고, 개선 방향을 제시하며, 긍정적인 방법으로 상대방을 돕는 피드백을 의미합니다. 핵심은 문제 해결을 돕고 상대방의 성장을 유도하는 것입니다.
"나쁘게 작성된 피드백"은 감정적이고 공격적인 표현이 포함된 피드백을 말합니다. 예를 들어, "이 코드는 정말 형편없다" 또는 "이건 완전 쓰레기 코드야" 같은 표현들은 문제를 지적하긴 하지만, 그 자체로 상처를 줄 수 있고 상대방이 방어적으로 반응하게 만들 수 있습니다.
피드백이 건설적인 내용이라도 그 전달 방식이 나쁘면 효과가 반감됩니다. 피드백은 존중과 배려를 바탕으로 전달되어야 하며, 이는 상대방의 성장을 돕는 방향으로 이루어져야 합니다. 피드백이 감정적이고 공격적이라면, 그것은 건설적이지 않으며, 오히려 반감을 사고 개선을 저해할 수 있습니다.
따라서 피드백을 나쁘게 작성하는 것은 절대 바람직하지 않으며, 어떤 형태로든 감정적인 공격이나 비난을 피하고, 문제 해결에 집중하는 방식으로 피드백을 제공하는 것이 중요합니다.
리뷰를 작성하는 사람이 화가 나거나 감정적으로 불편한 상황에서 마인드 컨트롤을 하는 것은 매우 중요합니다. 감정이 앞서면 피드백이 건설적이지 않거나 공격적으로 변할 수 있기 때문에, 효과적인 피드백을 주기 위해 감정을 잘 다스려야 합니다. 여기서는 감정을 통제하고, 더 생산적이고 건설적인 리뷰를 작성할 수 있는 방법을 제시해 드리겠습니다.
피드백을 주는 사람이 감정을 표현하는 것도 중요할 수 있습니다. 예를 들어, "이 부분을 보고 조금 놀랐어요"라든지 "이 코드를 보고 약간 당황했습니다"라고 솔직하게 감정을 표현할 수 있습니다. 단, 이 표현은 비판적이기보다는 이해와 개선을 위한 방식으로 전달해야 합니다.
화가 나거나 불편한 감정을 가지고 리뷰를 작성해야 할 때, 감정을 가라앉히고, 문제에 집중하는 것이 중요합니다. 감정을 잘 다스리고 객관적이고 건설적인 피드백을 제공하면, 피드백을 받는 사람도 더 잘 받아들이고 개선할 수 있습니다. 마인드 컨트롤을 통해 긍정적이고 생산적인 대화로 이어지게 함으로써, 팀의 성장을 촉진하고 협업 환경을 개선할 수 있습니다.
당신이 작성한 리뷰가 감정적인지 아닌지 확인하는 방법은 주로 언어의 선택, 톤, 그리고 피드백의 내용을 기준으로 분석할 수 있습니다. 감정적이지 않은 피드백은 객관적이고 건설적인 방향으로 제시되어야 하며, 감정을 배제하고 문제 해결에 집중하는 방식이어야 합니다. 아래는 감정적인 리뷰인지 아닌지를 점검할 수 있는 구체적인 방법들입니다:
사람을 비난하거나 공격하는 내용이 포함되면 감정적입니다. 예를 들어, "너무 실망했다" 또는 "이렇게 할 줄 몰랐다"는 피드백은 상대방의 능력 자체를 부정하는 느낌을 줄 수 있습니다. 코드나 작업을 비판하되, 그 행위에만 초점을 맞추고 사람 자체에 대한 비판을 피하는 것이 중요합니다. 예를 들어, "이 코드는 비효율적입니다. 효율성을 높이려면 이렇게 수정할 수 있습니다"와 같이 표현하면, 사람에 대한 공격 없이 문제 해결에 집중할 수 있습니다.
이 기준들을 통해 리뷰가 감정적이지 않은지 확인할 수 있으며, 객관적이고 건설적인 피드백을 제공하는 데 도움이 됩니다.
"이게 진짜 코드라고? 내가 이렇게 엉망인 코드를 본 건 처음이에요. 솔직히 말해서, 이건 코드도 아니에요. 그냥 아무렇게나 쓰레기처럼 던져놓은 것 같아요. 이 코드가 제대로 동작한다고 생각하나요? 무슨 생각으로 이렇게 짰는지 도저히 이해할 수 없어요. 내가 프로그래밍 처음 시작했을 때도 이런 실수는 안 했어요. 이건 그냥 기본도 모르는 수준이고, 내가 봤을 땐 아예 프로그래밍을 시작도 안 했을 수도 있을 것 같아요. 변수명? 그게 뭐죠? 대체 어떤 생각으로 저렇게 이름 지었는지 알 수가 없어요. 나 같으면 그거 한 줄만 봐도 몇 번이나 바꿨을 텐데. 주석은 왜 없는 건지, 그거 하나만 해도 기본 중의 기본이잖아요. 이런 것도 모르면 코드 리뷰 할 자격도 없어요. 나 때는 이런 기본적인 것 하나하나 신경 안 쓰면 그냥 팀에서 아예 말도 못 꺼냈어요. 이런 코드 보니까 차라리 내가 다시 짜는 게 낫겠어요. 이 코드는 한마디로 말해서 '시간 낭비'예요. 뭐 하나 제대로 짜지 못한 걸 제출하는 건 진짜 정신이 나간 사람만 할 짓이에요. 나중에 이 코드로 버그 잡으려고 고생하는 건 내가 아니라 다른 팀원들이에요. 그때 가서 후회하지 말고, 차라리 지금이라도 다 고쳐놓는 게 나아요. 이렇게 짜놓고 팀에서 인정받을 거라 생각한 거면 착각이에요. 내 눈엔 그냥 철학적으로도 부족한 코드, 초등학생 수준의 프로그래밍처럼 보이네요. 제발 이 코드로 다시 제출하지 마세요. 다들 당신을 두고 뭐라 할지 상상이 가네요."
"진짜, 이게 코드라고 제출한 거예요? 내가 이런 코드 보게 될 줄은 몰랐네요. 이걸 봤을 때, 예전에는 이런 걸 코딩이라 하지도 않았어요. '이 정도면 되겠지' 하고 짰다면, 그건 정말 초보자도 아니고 그냥 프로그래밍을 처음 접한 사람들만 하는 실수죠. 내가 20대 때는 이런 기본적인 부분은 다 이해하고 넘어갔었고, 이렇게 엉망으로 짜면 바로 코드 리뷰에서 지적받고 다시 처음부터 짰어요. 이 코드는 기본이 안 되어 있어요. 변수명? 뭐 하나 의미 있는 게 없네요. 그냥 아무렇게나 지은 것 같은데, 이렇게 하시면 안 됩니다. 옛날엔 변수명부터 팀에서 다 맞춰가며 코딩했죠. 그때는 누가 이렇게 엉망으로 짜면 다들 눈치챘어요. 주석도 없고, 코드가 뭐하는 건지 하나도 모르겠어요. 이걸 아무런 설명 없이 팀에 제출하다니, 정말 아무 생각 없이 일하는 것처럼 보이네요. 예전 같으면, 이런 코드 작성하면 내가 바로 교훈을 줬을 텐데요. 테스팅? 그게 뭐죠? 이 코드 보니까 테스트도 제대로 안 했겠죠. 나중에 버그 날 때 그 수습하는 거 생각하면 벌써부터 머리가 아파요. 요즘 사람들은 이렇게 기본도 안 지키는구나. 이건 다시 처음부터 새로 짜는 게 낫다고 봐요. 내가 봤을 땐 이 코드 보고 나서 다들 실망할 거예요. 과거에 내가 일하던 팀에서는 이런 코드 절대 용납 안 했어요. 진짜, 이제는 이런 것도 기본부터 다시 배워야 될 때인 거 같네요. 당장 이런 코드 다시 작성하지 않도록 신경 쓰세요."
"이 코드가 왜 이렇게 나왔는지 이해가 안 가네요. 예전엔 이런 것도 다 기본 중의 기본이었거든요. 이 코드, 정말 프로그래밍을 좀 한다는 사람은 절대 이렇게 작성하지 않아요. 이 정도면 아마 입사한 지 6개월도 안 된 초보자 수준 같아요. 변수명부터가 뭐가 뭔지 알 수가 없네요. 이런 식으로 짜면 나중에 팀원들이나 다른 개발자들이 얼마나 고생할지 생각은 해봤나요? 주석도 없고, 코드도 흐름이 하나도 안 보여요. 예전에 다들 이런 문제는 다 해결하고 넘어갔던 거고, 이런 기본적인 걸 못 하면 팀에서 일하는 게 어려워요. 왜 이런 코드를 제출한 건지 정말 이해가 안 돼요. '그냥 이렇게 하면 되겠지'라고 생각한 거 같은데, 그런 생각은 초보자가 하는 거고, 이렇게 짜놓고 테스트도 안 한 거 같고, 버그 나면 다른 사람이 고치려고 몇 배로 고생할 거예요. 이 코드는 정말 좀 심각해요. 지금 이걸 보고 내가 고쳐야 한다면, 다시 처음부터 새로 짜는 게 훨씬 나을 것 같아요. 옛날엔 이런 실수하면 다들 기본적으로 고쳤거든요. 아마 예전엔 팀에서도 이런 거 가지고 고쳐야 했으면 벌써 몇 번은 쫓겨났을 거예요. 나중에 이런 거 다시 하지 않도록 좀 더 신경 쓰세요."
GPT 꼰대력 장난이 아니다!